10 Tips On Standard Operating Procedures for MSPs in 2024

Standard operating procedures and the tips I have collected over the years to help you create an effective documentation strategy will be the topic of today’s article.

I will touch on what a standard operating procedure is and how to easily identify if it is a SOP versus a knowledgebase article. You can use any documentation platform to apply the tips I use here however I will be using ITGlue as the example in this article.

While you are here, Take a look at some of our other IT Business Consulting related articles below that may interest you:

• Little Known Facts On Managed Backups with MSPs
• Interesting Facts About Managed Services
• Common MSP Documentation Strategy Failures
• Common Vertical Automotive Applications
• Halo PSA And Why MSPs Are Moving

What Is A Standard Operating Procedure?

SOPs are like an instruction guide for your own business. So things like dress code and lunch breaks to the process involved in applying for leave.

Some would say that if you do not have a standard operating procedure then you do not really have a business to sell. The reason for this is that without a SOP, you are forcing people to assume how to operate on a day to day basis and more than likely that requires a key person (you) to be at least a phone call away if and when employees need guidance on how to approach a near infinite number of scenarios.

Standard Operating Procedures are actually quite difficult to templatize or duplicate because each organization is going to be at least slightly different. The best SOPs are those that are written from the ground up as your organization grows.

Is A SOP Part Of A Knowledgebase

Standard operating procedures can be part of a knowledge base however it could be argued that is an incorrect framework and that both should be kept separate. I have known a medium sized MSP that had the top level that was called the knowledgebase and the SOP was a subfolder under this. They were able to make it work however after 20 odd years of exposure to different strategies, I would avoid this type of setup. First, it is not standard meaning when you hire employees, you will have to train for this exception and that is just a wasted step in my book.

A knowledgebase as far as I and most other MSPs will define it is a repository for internal technical guides that is collected over time.

The way I set up the knowledge base internally is to have a single internal knowledgebase that holds two top level folders called internal and external. The internal folder holds a duplicate folder structure of the external plus any extra folders that may be relevant to the internal structure of the business such as a “datacenter” folder.

The external folder retains all client based technical instructions that could universally relate to all clients. So this means generic guides relating to setting up say an Apple Iphone or company notebook. I use the publish publicly in the documentation platform to create a public link that all clients can access for these generic guides.

Each client also has its own knowledgebase with an identical folder structure. Client specific technical guides are located in these and they are located under each client. 

So there should be multiple knowledge bases setup however there should only ever be one SOP for your entire organization. While clients may create their own SOP and you may assist them by providing the strategy and documentation framework to do this, that SOP has nothing to do with you the MSP and the reality is, you should not have any input into the clients SOP creation.

Depending on the size of your organization the standard operating procedures may need a full time resource to keep them up to date and complete. Below 50 staff it likely requires a few hours per week and then a sliding scale above that until around 100 staff and at that point it starts to become a full time job for someone.

It has been my experience that a non technical resource is best suited for this role as it prevents the confusion that occurs in technical staff as to where a document goes. A non tech staff member will never consider putting a SOP into the KB but a technician may.

Finally, a SOP is generally a prescriptive and formalized way of carrying out something from a very high level. Take offboarding a client for instance. There should be an SOP as well as a KB article for undertaking this.

The SOP will reference with a link to the top level KB article that will perhaps link to specific client KB articles. The SOP will be a high level procedure for offboarding a client such as the following:

1. Confirm offboarding with MSP Client Manager
2. Inform finance department with minimum 30 days notice
3. Email client following KB article 234232
4. Follow up with phone call to client within 7 days
5. Email client advising removal of agents following KB 4322
6. Email client offboarding separation form following KB 3267

As can be seen from this example, the SOP is general internal documentation on how to strategically undertake a process. It should not vary from client to client or situation to situation. The SOP should be universal in its application whenever in this example, an offboarding of a client is to take place.

Document All Operating Procedures - 1

It matters little if you are a large MSP that has its own cleaner or you do not have cleaners at all and you have an agreement with your landlord to clean your own spaces, there needs to be a standard operating procedure written up on who is responsible, when they are responsible, what areas they are responsible for and how often they are responsible for ensuring the areas your organization occupies are kept clean.

If you have outside cleaners then there should be a SOP on who is responsible for confirming they have undertaken the cleaning, what they have cleaned and if they have undertaken the work competently. Failing to do this will mean that you may well come back to an office that does not look out of place on the secret hoarders show and requires fumigation.

A real business needs to operate to the same level regardless as to if the CEO, director or owner has gone away for a month or not. 

SOPs Are Plain Language - 2

Ensure that your SOPs are written so they are easily understood by a person that has no specialist training. An example would be, say there is an SOP that explains the client onboarding process then that Standard operating procedure should be written so that it can be understood by the cleaner.

They may not be able to carry out the steps that point to specific KB articles that the SOP refers to but they should be able to comprehend what the SOP is asking to be done. By adhering to this rule, you guarantee that you do not trip up and assume an SOP is written whereby only half the target audience understands what needs to be done.

By always writing for the least knowledgeable, least experienced and lowest common denominator, you guarantee it can be comprehended by anyone that needs to follow it.

Assign Single Primary Contact - 3

Even if you have just started your own MSP it may be just you or one other staff member, ensure the role of managing standard operating procedures is not shared. My advice is not to delegate it when you are at such an early stage and regardless of your size, if you are embarking on a SOP creation for the first time then the company leadership should drive the project.

This is because only the leadership knows what a SOP should be. Say you get to the point where there are 3 to 5 staff and you have advised everyone that works for you that it is important that when they visit a client site, they must wear a tie and white shirt.

Now you bring on a senior tech and never had the chance to induct him correctly and after being away at a virtualization conference for a week you find out he has been attending client sites willy nilly without a tie and even worse, a pink shirt.

Now who is at fault here? The cause of this significant disaster has to fall back on you and the lack of having a written SOP on dress code.

It falls back onto you to write the initial SOP because you know what you want the dress code to be and nobody else can read your mind. This is one example out of hundreds where when your organization is small, you can get away without having standard operating procedures.

Nobody has the vision of how you want the company you lead to operate and without writing it down on your own, nobody else ever will.

Formatting And Consistency Are Vital - 4

This is linked to the point above and an added reason to have a single person responsible for the creation and maintenance of the standard operating procedures.

It is a problem that has plagued all organizations, it is a problem continually downplayed by staff tasked with maintaining both SOPs and KBs and that is ensuring whatever is written is done in a consistent manner both in how it is created, the fonts, the spacing, whether to use bullet points or numbers and where to use bold text or colored text.

An example is in ITGlue, you can directly insert photos into the text area or you can use the photo album feature. While I prefer to directly insert photos, it is not so much important which method you use, it is only important that you consistently use the same method every time.

Having multiple standard operating procedures that are radically different from each other guarantees that people will not trust them and as a result will not use them.

Writing Style Should Be The Same - 5

Yes you should have a standard operating procedure that outlines the writing style to be used. This includes the type of words that will be used, length of paragraphs and the general framework that each SOP will adhere to. 

Having radically different writing styles where one SOP is short and to the point with as few words as possible to convey a message and then the next looks like it has been written by Tom Clancy is not conducive to establishing trust among your staff.

Implement An Approvals Process - 6

Even if you are a one man operation, put an approval process in place so that as you scale, it allows you to scale as fast as is required. Ideally a single person would have been responsible for implementing whatever SOP structure you currently have in place.

Standard operating procedures however often change over time. Once you have the core SOP structure in place then ensuring that there is a rigid approvals process so that changes are handled the same way every time is very important.

In IT Glue, I used the workflow module to create a flagging system for SOPs that included triggers with webhooks in Microsoft Teams for when SOPs needed a review, to be archived or updated so that multiple personnel from multiple departments were able to make proposed changes while allowing the final signoff to be controlled by an individual familiar with the framework that needs to be adhered to.

Implement A Naming Convention - 7

Invest time ideally at the planning stage of implementing your standard operating procedure platform or retroactively at some point during its early growth phase.

I hear so many complaints about various applications' search ability and my view on this is that the search bar should be treated as a backup. You should build the SOP naming structure with the view that a search bar does not exist.

By doing this it forces you to come up with a naming convention that is both logical and easy to navigate. I like to break up the SOP into each major company section such as Finance/Engineering/Sales etc.

Consistently Review Usage Of SOP Articles - 8

All leading IT documentation platforms have a pathway to view their usage. Keeping an eye on how often SOP articles are used by your employees is important. If nobody is using them then something is wrong. 

Either the articles are written and published in an untrustworthy way, employees do not know of their existence or perhaps there is no discouragement for doing the wrong thing in your organization among many others.

The point is, you need analytics to establish if there is a problem before you begin trying to figure out what the problem is. 

If you do not have a documentation platform or yours does not have the ability then I strongly recommend investing in one. Hudu for instance can be purchased quite reasonably with a low license count. I suppose I do not see it as practical for MSPs to be operating in today's market without a documentation management platform. 

Market Your Standard Operating Procedures To Staff - 9

I have on occasion been shown an organization's SOPs that in reality end up being a cobbled together group of articles written over a decade that are wildly dissimilar in both their writing style and format located in a nondescript Sharepoint folder called “Operations”

Nobody knew where it was until I asked and the standard operating procedures written were often outdated and plain wrong. It is frustrating to note that someone at some point invested countless hours working on a company's SOPs only to have them shoved away in a dark corner and forgotten the moment “real work” like a new project or client needed attending to.

It is important that you engage in a consistent and ongoing marketing campaign to both new employees as well as long term staff. Links to the SOP located on every app they use within the business where appropriate. 

If you have signature management software then setting up all internal emails to have a link to your organization's standard operating procedures is a great idea. If you are really keen, throw it on the coffee cups too, whatever you can do to ensure that the SOP is always at the forefront of each one of your employees.

Regular Maintenance Of SOPs - 10

It can be frustrating when I go into a new organization and am pointed in the direction of their SOP to find out that there are references to a head office they moved from 5 years ago or Margerie the finance lady who retired in the late 90s is directly referenced.

To help with the regular maintenance of a SOP, it is important to ensure that it is never personalized. People move and companies move offices. This is where a documentation platform makes it a bit easier because these changing pieces of information are always independent of the SOP article itself.

Still even then people will occasionally write variable or changing information directly into a SOP. Always use tags for these types of information so that if it does change then the tagged information is updated during the offboarding or moving process and the SOP always points towards accurate information.

Depending on the size of the organization a SOP should be reviewed anywhere from daily to monthly but never more than that regardless of size. Proposed updates or additions should be put in place so that the SOP does not become stale.

It should be noted here that if your standard operating procedure becomes stale and your staff are either tripped up when trusting something that has become inaccurate or noticing errors before acting on them, then they will stop using the SOP due to the lack of trust these events cause. It takes very few instances where an employee is let down by the information to stop relying on it.

Ultimately what is the point of reading a procedure if there is a chance it is going to be wrong anyway, much easier just to ask someone that knows right? Of course that wastes the time of the employee looking to undertake the process as well as the staff member who has to stop what they are doing and explain what needs to be done.

Conclusion

Regardless of size, I hope this article has convinced you to invest time and effort into some type of standard operating procedure structure in your organization.

The two takeaways here are scalability and sale price. If you are on the smaller size, I am assuming you want to grow? This requires scalability both up and down as and when the market dictates. 

By having a SOP you can onboard new staff faster and with more confidence and less cost than if you need to invest time in one on one training.

If you are a larger MSP, then the sale price should be on your mind. Sure you may not yet be looking to move on or sell but without an SOP, all you have is a glorified job because you need to be available for the whole enterprise to work. This significantly impacts upon sale price of any business especially MSPs.

We have a number of other IT Support Partnership articles listed below that will provide you with more detailed information on a number of related topics:

https://optimizeddocs.com/blogs/consulting/consulting-index-page-01

Our team specializes in strategies for IT support centers and we assist in improving profit margins through standardization and consistent record keeping strategies, so you can be confident that our content is tailored to your needs.

Please feel free to explore our other articles and click on any that interest you. If you have any questions or would like to learn more about how we can help you with your documentation.